• /Admin/CallHistory.aspx [Referer HTTP header]
• /Admin/PendingCancels.aspx [__VIEWSTATEGENERATOR parameter]
• /Admin/PendingCancels.aspx [ctl00%24ContentPlaceHolder1%24dpEndDate parameter]
• /Admin/PendingCancels.aspx [ctl00%24ContentPlaceHolder1%24dpStartDate parameter]
• /Admin/PendingCancels.aspx [ctl00%24ContentPlaceHolder1%24dropLocation parameter]
• /ProgramTesting.aspx [__VIEWSTATEGENERATOR parameter]
• /ProgramTesting.aspx [dropClients parameter]
• /ProgramTesting.aspx [dropClients%24DDD%24L parameter]
• /ProgramTesting.aspx [dropClients_VI parameter]
• /ProgramTesting.aspx [txtSessionID parameter]
• /admin/RRNLookup.aspx [ctl00%24ContentPlaceHolder1%24dropSearchType%24DDD%24L parameter]
• /admin/SeratelManagement.aspx [__VIEWSTATEGENERATOR parameter]
• /admin/SeratelManagement.aspx [ctl00%24ContentPlaceHolder1%24btnSwap parameter]

Operating system command injection vulnerabilities arise when an application incorporates user-controllable data into a command that is processed by a shell command interpreter. If the user data is not strictly validated, an attacker can use shell metacharacters to modify the command that is executed, and inject arbitrary further commands that will be executed by the server.

OS command injection vulnerabilities are usually very serious and may lead to compromise of the server hosting the application, or of the application's own data and functionality. It may also be possible to use the server as a platform for attacks against other systems. The exact potential for exploitation depends upon the security context in which the command is executed, and the privileges that this context has regarding sensitive resources on the server.

If possible, applications should avoid incorporating user-controllable data into operating system commands. In almost every situation, there are safer alternative methods of performing server-level tasks, which cannot be manipulated to perform additional commands than the one intended.

If it is considered unavoidable to incorporate user-supplied data into operating system commands, the following two layers of defense should be used to prevent attacks:

• The user data should be strictly validated. Ideally, a whitelist of specific accepted values should be used. Otherwise, only short alphanumeric strings should be accepted. Input containing any other data, including any conceivable shell metacharacter or whitespace, should be rejected.
• The application should use command APIs that launch a specific process via its name and command-line parameters, rather than passing a command string to a shell interpreter that supports command chaining and redirection. For example, the Java API Runtime.exec and the ASP.NET API Process.Start do not support shell metacharacters. This defense can mitigate the impact of an attack even in the event that an attacker circumvents the input validation defenses.

• Web Security Academy: OS command injection

• CWE-77: Improper Neutralization of Special Elements used in a Command ('Command Injection')
• CWE-78: Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')
• CWE-116: Improper Encoding or Escaping of Output
• CAPEC-248: Command Injection

• /Admin/CallHistory.aspx [name of an arbitrarily supplied URL parameter]
• /Admin/ExternalEscalationQA.aspx [ctl00%24ContentPlaceHolder1%24dropPrograms2 parameter]
• /Admin/PendingCancels.aspx [__VIEWSTATEGENERATOR parameter]
• /Admin/PendingCancels.aspx [ctl00%24ContentPlaceHolder1%24dpEndDate parameter]
• /Admin/PendingCancels.aspx [ctl00%24ContentPlaceHolder1%24dpStartDate parameter]
• /Admin/PendingCancels.aspx [ctl00%24ContentPlaceHolder1%24dropLocation parameter]
• /Admin/PendingCancels.aspx [ctl00%24ContentPlaceHolder1%24dropLocation%24DDD%24L parameter]
• /Admin/PendingCancels.aspx [ctl00_ContentPlaceHolder1_dropLocation_VI parameter]
• /Admin/ProgramEditor.aspx [name of an arbitrarily supplied URL parameter]
• /ProgramTesting.aspx [__VIEWSTATEGENERATOR parameter]
• /ProgramTesting.aspx [dropClients parameter]
• /ProgramTesting.aspx [dropClients%24DDD%24L parameter]
• /ProgramTesting.aspx [dropClients_VI parameter]
• /ProgramTesting.aspx [dropPrograms_VI parameter]
• /ProgramTesting.aspx [txtSessionID parameter]
• /admin/EscalationQA.aspx [name of an arbitrarily supplied URL parameter]
• /admin/RRNLookup.aspx [ctl00%24ContentPlaceHolder1%24dropSearchType%24DDD%24L parameter]
• /admin/SeratelManagement.aspx [__VIEWSTATEGENERATOR parameter]
• /admin/SeratelManagement.aspx [ctl00%24ContentPlaceHolder1%24btnSwap parameter]

SQL injection vulnerabilities arise when user-controllable data is incorporated into database SQL queries in an unsafe manner. An attacker can supply crafted input to break out of the data context in which their input appears and interfere with the structure of the surrounding query.

A wide range of damaging attacks can often be delivered via SQL injection, including reading or modifying critical application data, interfering with application logic, escalating privileges within the database and taking control of the database server.

The most effective way to prevent SQL injection attacks is to use parameterized queries (also known as prepared statements) for all database access. This method uses two steps to incorporate potentially tainted data into SQL queries: first, the application specifies the structure of the query, leaving placeholders for each item of user input; second, the application specifies the contents of each placeholder. Because the structure of the query has already been defined in the first step, it is not possible for malformed data in the second step to interfere with the query structure. You should review the documentation for your database and application platform to determine the appropriate APIs which you can use to perform parameterized queries. It is strongly recommended that you parameterize every variable data item that is incorporated into database queries, even if it is not obviously tainted, to prevent oversights occurring and avoid vulnerabilities being introduced by changes elsewhere within the code base of the application.

You should be aware that some commonly employed and recommended mitigations for SQL injection vulnerabilities are not always effective:

• One common defense is to double up any single quotation marks appearing within user input before incorporating that input into a SQL query. This defense is designed to prevent malformed data from terminating the string into which it is inserted. However, if the data being incorporated into queries is numeric, then the defense may fail, because numeric data may not be encapsulated within quotes, in which case only a space is required to break out of the data context and interfere with the query. Further, in second-order SQL injection attacks, data that has been safely escaped when initially inserted into the database is subsequently read from the database and then passed back to it again. Quotation marks that have been doubled up initially will return to their original form when the data is reused, allowing the defense to be bypassed.
• Another often cited defense is to use stored procedures for database access. While stored procedures can provide security benefits, they are not guaranteed to prevent SQL injection attacks. The same kinds of vulnerabilities that arise within standard dynamic SQL queries can arise if any SQL is dynamically constructed within stored procedures. Further, even if the procedure is sound, SQL injection can arise if the procedure is invoked in an unsafe manner using user-controllable data.

• Web Security Academy: SQL injection
• Using Burp to Test for Injection Flaws
• Web Security Academy: SQL Injection Cheat Sheet

• CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
• CWE-94: Improper Control of Generation of Code ('Code Injection')
• CWE-116: Improper Encoding or Escaping of Output
• CAPEC-66: SQL Injection

Server-side code injection vulnerabilities arise when an application incorporates user-controllable data into a string that is dynamically evaluated by a code interpreter. If the user data is not strictly validated, an attacker can use crafted input to modify the code to be executed, and inject arbitrary code that will be executed by the server.

Server-side code injection vulnerabilities are usually very serious and lead to complete compromise of the application's data and functionality, and often of the server that is hosting the application. It may also be possible to use the server as a platform for further attacks against other systems.

Whenever possible, applications should avoid incorporating user-controllable data into dynamically evaluated code. In almost every situation, there are safer alternative methods of implementing application functions, which cannot be manipulated to inject arbitrary code into the server's processing.

If it is considered unavoidable to incorporate user-supplied data into dynamically evaluated code, then the data should be strictly validated. Ideally, a whitelist of specific accepted values should be used. Otherwise, only short alphanumeric strings should be accepted. Input containing any other data, including any conceivable code metacharacters, should be rejected.

• CWE-94: Improper Control of Generation of Code ('Code Injection')
• CWE-116: Improper Encoding or Escaping of Output
• CWE-159: Failure to Sanitize Special Element
• CAPEC-193: PHP Remote File Inclusion
• CAPEC-242: Code Injection
• CAPEC-252: PHP Local File Inclusion

• /Admin/PendingCancels.aspx [ctl00%24ContentPlaceHolder1%24dpStartDate parameter]
• /ProgramTesting.aspx [dropClients_VI parameter]

Server-side code injection vulnerabilities arise when an application incorporates user-controllable data into a string that is dynamically evaluated by a code interpreter. If the user data is not strictly validated, an attacker can use crafted input to modify the code to be executed, and inject arbitrary code that will be executed by the server.

Server-side code injection vulnerabilities are usually very serious and lead to complete compromise of the application's data and functionality, and often of the server that is hosting the application. It may also be possible to use the server as a platform for further attacks against other systems.

Whenever possible, applications should avoid incorporating user-controllable data into dynamically evaluated code. In almost every situation, there are safer alternative methods of implementing application functions, which cannot be manipulated to inject arbitrary code into the server's processing.

If it is considered unavoidable to incorporate user-supplied data into dynamically evaluated code, then the data should be strictly validated. Ideally, a whitelist of specific accepted values should be used. Otherwise, only short alphanumeric strings should be accepted. Input containing any other data, including any conceivable code metacharacters, should be rejected.

• CWE-94: Improper Control of Generation of Code ('Code Injection')
• CWE-95: Improper Neutralization of Directives in Dynamically Evaluated Code ('Eval Injection')
• CWE-116: Improper Encoding or Escaping of Output
• CAPEC-242: Code Injection

• /Admin/CallHistory.aspx [name of an arbitrarily supplied URL parameter]
• /Admin/PendingCancels.aspx [__VIEWSTATEGENERATOR parameter]
• /Admin/PendingCancels.aspx [ctl00%24ContentPlaceHolder1%24dpEndDate parameter]
• /Admin/PendingCancels.aspx [ctl00%24ContentPlaceHolder1%24dpStartDate parameter]
• /Admin/PendingCancels.aspx [ctl00%24ContentPlaceHolder1%24dropLocation%24DDD%24L parameter]
• /Admin/PendingCancels.aspx [ctl00_ContentPlaceHolder1_dropLocation_VI parameter]
• /Admin/ProgramEditor.aspx [name of an arbitrarily supplied URL parameter]
• /Admin/SeratelManagement.aspx [ctl00%24ContentPlaceHolder1%24btnSwap parameter]
• /ProgramTesting.aspx [__VIEWSTATEGENERATOR parameter]
• /ProgramTesting.aspx [dropClients parameter]
• /ProgramTesting.aspx [dropClients parameter]
• /ProgramTesting.aspx [dropClients%24DDD%24L parameter]
• /ProgramTesting.aspx [dropClients%24DDD%24L parameter]
• /ProgramTesting.aspx [dropPrograms_VI parameter]
• /ProgramTesting.aspx [txtSessionID parameter]
• /ProgramTesting.aspx [txtSessionID parameter]
• /admin/RRNLookup.aspx [ctl00%24ContentPlaceHolder1%24dropSearchType%24DDD%24L parameter]
• /admin/SeratelManagement.aspx [__VIEWSTATEGENERATOR parameter]
• /admin/SeratelManagement.aspx [ctl00%24ContentPlaceHolder1%24btnSwap parameter]

Server-side code injection vulnerabilities arise when an application incorporates user-controllable data into a string that is dynamically evaluated by a code interpreter. If the user data is not strictly validated, an attacker can use crafted input to modify the code to be executed, and inject arbitrary code that will be executed by the server.

Server-side code injection vulnerabilities are usually very serious and lead to complete compromise of the application's data and functionality, and often of the server that is hosting the application. It may also be possible to use the server as a platform for further attacks against other systems.

Whenever possible, applications should avoid incorporating user-controllable data into dynamically evaluated code. In almost every situation, there are safer alternative methods of implementing application functions, which cannot be manipulated to inject arbitrary code into the server's processing.

If it is considered unavoidable to incorporate user-supplied data into dynamically evaluated code, then the data should be strictly validated. Ideally, a whitelist of specific accepted values should be used. Otherwise, only short alphanumeric strings should be accepted. Input containing any other data, including any conceivable code metacharacters, should be rejected.

• CWE-94: Improper Control of Generation of Code ('Code Injection')
• CWE-95: Improper Neutralization of Directives in Dynamically Evaluated Code ('Eval Injection')
• CWE-116: Improper Encoding or Escaping of Output
• CAPEC-242: Code Injection

HTTP request smuggling vulnerabilities arise when websites route HTTP requests through web servers with inconsistent HTTP parsing.

By supplying a request that different servers interpret as having different lengths, an attacker can poison the back-end TCP/TLS socket and prepend arbitrary data to the next request. Depending on the website's functionality, this can be used to bypass front-end security rules, access internal systems, poison web caches, and launch assorted attacks on users who are actively browsing the site.

You can resolve all variants of this vulnerability by configuring the front-end server to exclusively use HTTP/2 when communicating with back-end systems. Alternatively, you could ensure all servers in the chain run the same web server software with the same configuration. Disabling back-end connection reuse is likely to reduce the impact of this vulnerability, but does not mitigate all possible exploits.

Specific instances of this vulnerability can be resolved by reconfiguring the front-end server to normalize ambiguous requests before routing them onward. Alternatively, you could configure the back-end server to reject the message and close the connection when it encounters an ambiguous request.

• HTTP Request Smuggling
• HTTP Desync Attacks

• CWE-444: Inconsistent Interpretation of HTTP Requests ('HTTP Request Smuggling')
• CAPEC-33: HTTP Request Smuggling

• ASP.NET_SessionId

If the secure flag is set on a cookie, then browsers will not submit the cookie in any requests that use an unencrypted HTTP connection, thereby preventing the cookie from being trivially intercepted by an attacker monitoring network traffic. If the secure flag is not set, then the cookie will be transmitted in clear-text if the user visits any HTTP URLs within the cookie's scope. An attacker may be able to induce this event by feeding a user suitable links, either directly or via another web site. Even if the domain that issued the cookie does not host any content that is accessed over HTTP, an attacker may be able to use links of the form http://example.com:443/ to perform the same attack.

To exploit this vulnerability, an attacker must be suitably positioned to eavesdrop on the victim's network traffic. This scenario typically occurs when a client communicates with the server over an insecure connection such as public Wi-Fi, or a corporate or home network that is shared with a compromised computer. Common defenses such as switched networks are not sufficient to prevent this. An attacker situated in the user's ISP or the application's hosting infrastructure could also perform this attack. Note that an advanced adversary could potentially target any connection made over the Internet's core infrastructure.

The secure flag should be set on all cookies that are used for transmitting sensitive data when accessing content over HTTPS. If cookies are used to transmit session tokens, then areas of the application that are accessed over HTTPS should employ their own session handling mechanism, and the session tokens used should never be transmitted over unencrypted communications.

• CWE-614: Sensitive Cookie in HTTPS Session Without 'Secure' Attribute

We observed a vulnerable JavaScript library.

We detected jquery version 3.1.1, which has the following vulnerabilities:

• CVE-2019-11358: jQuery before 3.4.0, as used in Drupal, Backdrop CMS, and other products, mishandles jQuery.extend(true, {}, ...) because of Object.prototype pollution
  
• CVE-2020-11022: Regex in its jQuery.htmlPrefilter sometimes may introduce XSS
  
• CVE-2020-11023: Regex in its jQuery.htmlPrefilter sometimes may introduce XSS
  

The use of third-party JavaScript libraries can introduce a range of DOM-based vulnerabilities, including some that can be used to hijack user accounts like DOM-XSS.

Common JavaScript libraries typically enjoy the benefit of being heavily audited. This may mean that bugs are quickly identified and patched upstream, resulting in a steady stream of security updates that need to be applied. Although it may be tempting to ignore updates, using a library with missing security patches can make your website exceptionally easy to exploit. Therefore, it's important to ensure that any available security updates are applied promptly.

Some library vulnerabilities expose every application that imports the library, but others only affect applications that use certain library features. Accurately identifying which library vulnerabilities apply to your website can be difficult, so we recommend applying all available security updates regardless.

Develop a patch-management strategy to ensure that security updates are promptly applied to all third-party libraries in your application. Also, consider reducing your attack surface by removing any libraries that are no longer in use.

• CWE-1104: Use of Unmaintained Third Party Components
• A9: Using Components with Known Vulnerabilities

• /Admin/CancellationCodes.aspx
• /Admin/CancellationCodes.aspx
• /Admin/CancellationCodes.aspx
• /Admin/CancellationCodes.aspx
• /Admin/CancellationCodes.aspx
• /Admin/CancellationCodes.aspx
• /Admin/CancellationCodes.aspx
• /Admin/CancellationCodes.aspx
• /Admin/CancellationCodes.aspx
• /Admin/CancellationCodes.aspx
• /Admin/CoverageCodes.aspx
• /Admin/CoverageCodes.aspx
• /Admin/CoverageCodes.aspx
• /Admin/CoverageCodes.aspx
• /Admin/CoverageCodes.aspx
• /Admin/CoverageCodes.aspx
• /Admin/CoverageCodes.aspx
• /Admin/CoverageCodes.aspx
• /Admin/CoverageCodes.aspx
• /Admin/CoverageCodes.aspx
• /Admin/ExternalEscalationQA.aspx
• /Admin/ExternalEscalationQA.aspx
• /Admin/ExternalEscalationQA.aspx
• /Admin/ExternalEscalationQA.aspx
• /Admin/ExternalEscalationQA.aspx
• /Admin/ExternalEscalationQA.aspx
• /Admin/ExternalEscalationQA.aspx
• /Admin/ExternalEscalationQA.aspx
• /Admin/ExternalEscalationQA.aspx
• /Admin/ExternalEscalationQA.aspx
• /Admin/PendingCancels.aspx
• /Admin/PendingCancels.aspx
• /Admin/PendingCancels.aspx
• /Admin/PendingCancels.aspx
• /Admin/PendingCancels.aspx
• /Admin/PendingCancels.aspx
• /Admin/PendingCancels.aspx
• /Admin/PendingCancels.aspx
• /Admin/PendingCancels.aspx
• /Admin/PendingCancels.aspx
• /Admin/SeratelManagement.aspx
• /Admin/SeratelManagement.aspx
• /Admin/SeratelManagement.aspx
• /Admin/SeratelManagement.aspx
• /Admin/SeratelManagement.aspx
• /Admin/SeratelManagement.aspx
• /Admin/SeratelManagement.aspx
• /Admin/SeratelManagement.aspx
• /Admin/SeratelManagement.aspx
• /Admin/SeratelManagement.aspx
• /Admin/TransactionSearch.aspx
• /Admin/TransactionSearch.aspx
• /Admin/TransactionSearch.aspx
• /Admin/TransactionSearch.aspx
• /Admin/TransactionSearch.aspx
• /Admin/TransactionSearch.aspx
• /Admin/TransactionSearch.aspx
• /Admin/TransactionSearch.aspx
• /Admin/TransactionSearch.aspx
• /Admin/TransactionSearch.aspx
• /Admin/UserManagement.aspx
• /Admin/UserManagement.aspx
• /Admin/UserManagement.aspx
• /Admin/UserManagement.aspx
• /Admin/UserManagement.aspx
• /Admin/UserManagement.aspx
• /Admin/UserManagement.aspx
• /Admin/UserManagement.aspx
• /Admin/UserManagement.aspx
• /Admin/UserManagement.aspx
• /ProgramTesting.aspx
• /ProgramTesting.aspx
• /ProgramTesting.aspx
• /ProgramTesting.aspx
• /ProgramTesting.aspx
• /ProgramTesting.aspx
• /ProgramTesting.aspx
• /ProgramTesting.aspx
• /ProgramTesting.aspx
• /ProgramTesting.aspx
• /WebResource.axd
• /WebResource.axd
• /WebResource.axd
• /WebResource.axd
• /WebResource.axd
• /WebResource.axd
• /WebResource.axd
• /WebResource.axd
• /WebResource.axd
• /WebResource.axd
• /admin/RRNLookup.aspx
• /admin/RRNLookup.aspx
• /admin/RRNLookup.aspx
• /admin/RRNLookup.aspx
• /admin/RRNLookup.aspx
• /admin/RRNLookup.aspx
• /admin/RRNLookup.aspx
• /admin/RRNLookup.aspx
• /admin/RRNLookup.aspx
• /admin/RRNLookup.aspx

DOM-based vulnerabilities arise when a client-side script reads data from a controllable part of the DOM (for example, the URL) and processes this data in an unsafe way.

DOM-based open redirection arises when a script writes controllable data into the target of a redirection in an unsafe way. An attacker may be able to use the vulnerability to construct a URL that, if visited by another application user, will cause a redirection to an arbitrary external domain. This behavior can be leveraged to facilitate phishing attacks against users of the application. The ability to use an authentic application URL, targeting the correct domain and with a valid SSL certificate (if SSL is used), lends credibility to the phishing attack because many users, even if they verify these features, will not notice the subsequent redirection to a different domain.

Note: If an attacker is able to control the start of the string that is passed to the redirection API, then it may be possible to escalate this vulnerability into a JavaScript injection attack, by using a URL with the javascript: pseudo-protocol to execute arbitrary script code when the URL is processed by the browser.

Burp Suite automatically identifies this issue using static code analysis, which may lead to false positives that are not actually exploitable. The relevant code and execution paths should be reviewed to determine whether this vulnerability is indeed present, or whether mitigations are in place that would prevent exploitation.

The most effective way to avoid DOM-based open redirection vulnerabilities is not to dynamically set redirection targets using data that originated from any untrusted source. If the desired functionality of the application means that this behavior is unavoidable, then defenses must be implemented within the client-side code to prevent malicious data from introducing an arbitrary URL as a redirection target. In general, this is best achieved by using a whitelist of URLs that are permitted redirection targets, and strictly validating the target against this list before performing the redirection.

• Web Security Academy: Open redirection (DOM-based)

• CWE-601: URL Redirection to Untrusted Site ('Open Redirect')